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SYSTEM AND METHOD FOR 
ENABLING MULTICAST TELECOMMUNICATIONS 



CROSS-REFERENCE TO RELATED APPLICATIONS 

This application is filed concurrently with the 
following commonly- owned applications: 

SYSTEM AND METHOD FOR PROVIDING SECURITY IN A 
TELECOMMUNICATION NETWORK, Attorney Docket 062891 . 0292 ; 

SYSTEM AND METHOD FOR MAINTAINING A COMMUNICATION LINK, 
Attorney Docket 062891.0293; and 

SYSTEM AND METHOD FOR A VIRTUAL TELEPHONY INTERMEDIARY, 
Attorney Docket 062891.0381. 

TECHNICAL FIELD OF THE INVENTION 

This invention relates generally to the field of 
telecommunications, and more specifically to a system and 
method for enabling multicast telecommunications. 
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BACKGROUND OF THE INVENTION 

Historically, telecommunications have involved the 
transmission of voice and fax signals over a network 
dedicated to telecommunications, such as the Public 
Switched Telephone Network (PSTN) or a Private Branch 
Exchange (PBX) . Similarly, data communications between 
computers have also historically been transmitted on a 
dedicated data network, such as a local area network (LAN) 
or a wide area network (WAN) . Currently, telecommunications 
and data transmissions are being merged into an integrated 
communication network using technologies such as Voice over 
Internet Protocol (VoIP) . Since many LANs and WANs transmit 
computer data using Internet Protocol (IP) , VoIP uses this 
existing technology to transmit voice and fax signals by 
converting these signals into digital data for transmission 
over an IP network. Although integrating telecommunications 
into existing data networks provides many advantages, this 
integration does create additional network traffic which 
can create problems in networks with insufficient 
bandwidth. 
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SUMMARY OF THE INVENTION 

In accordance with the present invention, a system and 
method for enabling multicast telecommunications is 
provided that substantially eliminates or reduces 
disadvantages or problems associated with previously 
developed systems and methods. In particular, the present 
invention contemplates an apparatus and method for coupling 
unicast telephony devices and multicast telephony devices. 
The present invention enables multicast telephony devices 
to communicate with each other using multicast streaming 

while still allowing unicast tele phony dev.i.ces to, 

participate . 

I^ one embodiment of the present invention, a method 
is provided for enabling a multicast telecommunication 
session. The method includes receiving muLticast media 
streaming sent J:o a_multica,st_group_addres.s at a multicast 
±^Z^^^^diI^Z~ The method further includes communicating 
tt^e^nr~«tr-^^ming_to^^ telep h ony device to enable 

-t-Ke~n5i^iit^elephony deyj^_to_participate in a multicast 
0 telecommunication__session^ 

' " ^I^T'I^Jothe^^embodiment of the present invention, a 
communication network is provided that includes a unicast 
telephony device, and a plurality of multicast telephony 
devices operable to receive multicast media streaming 
5 transmitted to a multicast group address. The communication 
network further includes a multicast intermediary operable 
to receive multicast media streaming sent to the multicast 
group address. The multicast intermediary is further 
operable to r^ommnni cate the media_st _reaming to the unicast 
0 tTlipho^ifdi^^i^TTT^ble the unicast telephony device to 
•^^^^I^ate in the multicast communication with the 
multicast telephony devices. 
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Technical advantages of the present invention include 
a system and method that allow unicast telephony devices to 
effectively participate in a telecommunication session with 
multicast telephony devices. Using a multicast intermediary 
to act on behalf of the unicast telephony devices, the 
multicast telephony devices and the multicast intermediary 
are able to communicate using multicast. The_multicast 
interm^diary._uses_^i£ast to Jprward^ll^mUA^^ 
streaming from the_ multicast^,J:^lephony,,..devi^^^ 
;^^jl^l^r~t^"^pt^y_, devicg.s^ In this manner, multicast 
teTi^h^ii^devices are able to take advantage of the 
multicast feature, while still being able to communicate 
with the unicast telephony devices, which reduces network 
traffic and saves network bandwidth. 

Useful applications of the present invention include 
client summing multicast conferences between unicast and 
multicast devices, music on hold transmitted to multicast 
and unicast devices, and silent monitoring of multicast 
calls by one or more unicast devices. Other technical 
advantages are readily apparent to one skilled in the art 
from the following figures, descriptions, and claims. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

For a more complete understanding of the present 
invention, and for further features and advantages, 
reference is now made to the following description, taken 
in conjunction with the accompanying drawings, in which: 

FIGURE 1 illustrates an exemplary communication 
network in accordance with the present invention; 

FIGURE 2 illustrates an exemplary communication link 
between network devices using a virtual telephony device ; 

FIGURE 3 illustrates another exemplary communication 
link between network devices using a virtual telephony 
device ; 

FIGURE 4 illustrates "a communication link established 
between multicast telephony devices and a unicast telephony 
device using a multicast intermediary; 

FIGURE 5 illustrates a communication link established 
between a plurality of multicast telephony devices and a 
plurality of unicast telephony devices using a plurality of 
multicast intermediaries; and 

FIGURE 6 illustrates a communication link established 
between a plurality of multicast ■ telephony devices and a 
plurality of unicast telephony devices using a single 
multicast intermediary. 
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DETAILED DESCRIPTION OF THE INVENTION 

FIGURE 1 illustrates an exemplary communication 
network 10. In the illustrated embodiment, communication 
network 10 includes a plurality of local area networks 
(LANs) 20 interconnected using a wide area network (WAN) 
30. Each LAN 2 0 is a computer data network that is further 
operable to transmit audio and/or video (media) 
telecommunication signals. In the particular embodiment 
illustrated in FIGURE 1, LANs 20 are Internet Protocol (IP) 
networks. However, LANs 20 may be any type of network that 
allows the transmission of media telecommunications, as 
well as traditional data communications. Therefore, 
although subsequent description will primarily focus on IP 
telephony devices, it should be understood that other 
appropriate telephony devices, such as Voice over Frame 
Relay devices, are also included within the scope of this 
description. Furthermore, although a specific communication 
network is illustrated in FIGURE 1, the term "communication 
network" should be interpreted as generically defining any 
network capable of transmitting telecommunication signals, 
data, and other types of signals and messages. 

LANS 20 may be directly coupled to other IP networks 
including, but not limited to, WAN 30 and any IP networks 
coupled to WAN ,30 (such as other LANs 2 0 or the Internet 
40) . Since all IP networks share a common method of 
transmitting data, telecommunication signals may be 
transmitted between telephony devices located on different, 
but interconnected, IP networks. In addition to being 
coupled to other IP networks, LANs 20 may also be coupled 
to non-IP telecommunication networks through the use of 
gateways. For example, LAN 20a is coupled to a private 
branch exchange (PBX) 50 through a gateway 52. PBX 50 
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represents the analog and/or digital telephone systems 
typically used by businesses. PBX 50 includes a plurali-ty 
of extension telephones (or subscriber sets) 54a and 54b to 
which PBX 50 directs incoming telephone calls. Gateway 52 
may be either an analog or a digital gateway depending on 
the type of PBX 50 to which it is coupled. The operation of 
the gateways in communication network 10 is described in 

further detail below. 

Another non- IP network to which LANs 20 may be coupled 
is the Public Switched Telephone Network (PSTN) 60. PSTN 60 
includes switching stations, central offices, mobile 
telephone switching offices, pager switching offices, 
remote terminals, and other related telecommunication 
equipment that are located across the country. For example, 
central offices (COs) 62 connect telephone customers, such 
as residences and businesses, to PSTN 60. In the . 
illustrated embodiment, LANs 20 are coupled to selected 
central offices 62 through the use of gateways 64, 
described below. Central offices 62 are coupled through a 
long distance network 66 that allows communication between 
residences and businesses coupled to central offices 62 in 
different areas, such as CO 62a in Dallas or CO 62b in San 
Jose . 

IP networks transmit data (including voice and video 
data) by placing the data in packets and sending each 
packet to the selected destination. The technology that 
allows telecommunications to be transmitted over an IP 
network may be referred to as Voice over IP (VoIP) . IP 
telephony devices 22-24 are coupled to LAN 20a to allow 
such communication over LAN 20a. IP telephony devices 22-24 
have the capability of encapsulating a user-s voice (or 
other media inputs) into IP packets so that the media can 
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be transmitted over LAN 20a, WAN 30 and/or Internet 40. IP 
telephony devices may include telephones, fax machines, 
computers running telephony software (such as MICROSOFT 
NETMEETING), analog or digital gateways, or any other 
device capable of performing telephony functions using an 
IP network. 

An IP telephony device may resemble a traditional 
digital PBX telephony device, but instead of connecting to 
a proprietary PBX port, the telephony device plugs into a 
LAN jack, such as an Ethernet jack. Alternatively, a user 
may plug a handset or headset directly into a personal 
computer 24 on LAN 20 to form a virtual IP telephony 
device. An IP telephony device operates as a standard IP 
network device and typically has its own IP address (which 
may be assigned dynamically) . IP telephony devices may have 
the ability to handle data coding and decoding at the 
telephony device. This feature allows the telephony device 
to switch audio encoding schemes on demand, such as 
switching between G.711 and G.723 encoding. 

A call manager 2 6a controls IP telephony devices 22-24 
(a similar call manager 2 6b may be located on LAN 2 0b) . 
Call manager 26a is an application that controls call 
processing, routing, telephone features and options (such 
as call hold, call transfer and caller ID), device 
configuration, and other telephony functions and parameters 
within communication network 10. Call manager 26a can 
control all of the IP telephony devices on LAN 20a, and it 
may also control IP telephony devices located across WAN 
30. For example, call manager 26a is capable of controlling 
telephony devices on LAN 2 0b. Thus, call manager 26b may be 
eliminated entirely or used as a redundant controller. 

When a user wishes to place a call from one IP 
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telephony device on LAN 20a to another IP telephony device 
on LAN 20a (an intra-LAN call) , the originating telephony 
device transmits a signal to call manager 26a indicating 
the desired function and the telephony device to be called. 
Call manager 26a then checks on the availability of the 
target telephony device and, if available, sets up the call 
by instructing the originating telephony device to 
establish a media stream with the target telephony device. 
The initial signaling between call manager 26a and either 
the originating telephony device or the target telephony 
device is transmitted over LAN 2 0a (and, if necessary, WAN 
3 0) using a communication protocol, such as the 
Transmission Control Protocol (TCP) . 

The TCP layer in the transmitting telephony device 
divides the data to be transmitted into one or more 
packets, numbers the packets, and then forwards them to the 
IP network layer for transmission to the destination 
telephony device. Although each packet has the same 
destination IP address, the packets may travel along 
different paths to reach the intended destination. As the 
packets reach the destination telephony device, the TCP 
layer in the destination telephony device reassembles the 
individual packets and ensures that they all have arrived. 
Once TCP reassembles the data, the protocol forwards the 
data to the appropriate application or other software 
module in the destination telephony device as a single 
message . 

After call manager 26a initiates the call with 
signaling over TCP, a codec (coder/decoder) converts the 
voice, video or fax signals generated by the users of the 
telephony devices from analog voice signals into digital 
form. The codec may be implemented either in software or as 
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special -purpose hardware in IP telephony devices 22-24. In 
the case of an IP telephone, as the user speaks into the 
handset, the codec converts the analog voice signals into 

digital data. The___digitally encoded data is then__ 

encapsulated into_2P_packets_^ that^^ 
over LAN 2 0a. 

~ Thli^'^^^Slpsulation may be performed by Real-Time 

Transport Protocol ^RTP) running over User Datagram 
Protocol (UDP) , or any other suitable communication 
protocols. "AT^ith TCP, UDP uses the Internet Protocol to 
get data packets from one device to another. Unlike TCP, 
however, UDP does not provide sequencing and error-checking 
of the arriving packets. However, since UDP does not 
perform these functions, UDP operates faster than TCP and 
is useful when speed is more important than accuracy. This 
is true of media streaming since it is critical that the 
data be transmitted as quickly as possible, but it is not 
critical that every single packet is reassembled correctly 
(either its absence is negligible or its content can be 
extrapolated by the destination telephony device) . Once UDP 
has received and reassembled the IP packets at the 
destination telephony device, a codec in the destination 
telephony device translates the digital data into analog 
audio and/or video signals for presentation to the user. 
The entire process is repeated each time that any call 
participant (or any other source) generates an audio, 

video, or fax signal. 

In addition to intra-LAN calls, calls can also be 
placed to and received from non-IP telephony devices 54, 68 
that are connected to PBX 50 or PSTN 60. Such calls are 
made through a gateway 52, 64. Because gateway 52 performs 
similarly to gateways 64, only gateways 64 will be 
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discussed in further detail. Each gateway 64 converts 
analog or digital circuit -switched data transmitted by PSTN 
60 to packetized data transmitted by LAN 20, and vice- 
versa. When media packets are transmitted from LAN 20, 
gateway 64 retrieves the data contained in the incoming 
packets and converts this digital data to the analog or 
digital format used by the PSTN trunk to which gateway 64 

is coupled. S ince t he digital _format_^or voice_ 

transmissions over an I P ne t workJ^__of t,en_^diff ere^ 



Th^format us^~5irth^igital trunks of PSTN 60^ gateway 
"eT^p^ovrdes^-a—conversion-betwe-MT^ 

lormat^ referred to as T^'^ ^^di^^gT ^Gateway 64 also 
l:ranslates between the~v5lF~^l control system and the 
Signaling System 7 (SS7) protocol or other signaling 
protocols used in PSTN. 60. 

For voice transmissions from PSTN 60 to LAN 20, the 
process is reversed. Gateway 64 takes the incoming voice 
transmission (in either analog or digital form) and 
converts it into the digital format used by LAN 20. The 
digital data is then encapsulated into IP packets and 
transmitted over LAN 20. 

When placing a call to a PSTN telephony device 68 from 
IP telephony device 22 on LAN 20a, the voice or fax signal 
generated by the user of IP telephony device 22 is 
digitized and encapsulated, as described above. The packets 
are then transmitted over LAN 20a to gateway 64. If more 
than one PSTN gateway 64 is coupled to LAN 20a, call 
manager 26a determines which gateway 64 is to receive the 
transmission based on the telephone number (e.g., the North 
American Numbering Plan (NANP) number) of the PSTN 
telephony device. Gateway 64 retrieves the IP packets and 
converts the data to the format (either digital or analog) 
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used by the PSTN trunk to which the gateway is connected. 
The voice signals are then sent to PSTN telephony device 68 
over PSTN 60. This process, and the reverse process, is 
continued between PSTN 60 and LAN 2 0a through gateway 64 
until the call is complete. 

Calls can also be made between an IP telephony device 
located on a LAN 20 and another IP telephony device located 
on another LAN 20, across WAN 30, or on Internet 40. For 
example, a call may be placed between IP telephony device 
22 connected to LAN 2 0a and IP telephony device 2 5 
connected to LAN 20b. As discussed above, the analog voice 
or fax data is digitized and encapsulated into IP packets 
at the originating IP telephony device 22. However, unlike 
communications with telephony devices on PSTN 60, gateway 
64 is not needed to convert the IP packets to another 
format. Instead, a router (or other similar device) directs 
the packets to the IP address of target IP telephony device 
25. IP telephony device 25 then retrieves the data and 
coverts it to analog form for presentation to the user. 
Either call manager 26a or call manger 26b (on LAN 20b) may 
control IP telephony device 25. 

When a call is placed to an IP telephony device, for 
example IP telephony device 22, a ^1 initiation re.giiag£ 
sen t to call man aga^-26a. If the originating 
telephony device is an IP telephony device (e.g., an intra- 
LAN or inter-LAN IP call) , the originating IP telephony 
device generates the call initiation request and sends the 
request to call manager 26a. If the originating telephony 
device is a non-IP telephony device, such as PSTN telephony 
device 68, gateway 64a first receives the incoming call 
from CO 62a, and sends a call initiation request to call 
manager 2 6a indicating the IP telephony device that is 
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being called. In either case, once call manager 26a 
receives the call initiation request, call manager 26a 
sends a signal to IP telephony device 22 offering the call 
to the telephony device. 

If IP telephony device 22 can accept the call (e.g., 
it is not in use or under a Do Not Disturb instruction from 
the user) , IP telephony device 22 replies to call manager 
26a that it will accept the call. Upon receiving this 
acceptance, call manager 2 6a transmits a signal to IP 
telephony device 22 to cause it to ring. The telephony 
device's user can then hear the ring and can take the 
telephony device "off -hook" to receive the call. Taking the 
telephony device off -hook may include, but is not limited 
to, picking up a handset, pressing the ringing line's 
button, pressing a speakerphone button, or otherwise 
indicating that the telephony device is ready to receive 
the incoming call. For the purposes of this application, 
the term "off -hook" is used to generically indicate a 
condition of a telephony device when it is ready to 
initiate or receive telecommunication signals. 

' Once IP telephony device 22 has been taken off -hook, 
call manager 26a instructs IP telephony device 22 and the 
originating telephony device to begin media streaming to 
each other. If the originating telephony device is a non-IP 
telephony device, such as PSTN telephony device 68, this 
media streaming occurs between IP telephony device 22 and 
gateway 64. Gateway 64 then transmits the media to PSTN 

telephony device 68. 

One advantage associated with IP telephony devices is 
their ability to communicate and interact with any other IP 
device coupled to the IP network. For example, IP telephony 
devices may interact and communicate with other IP 



20 



30 




m 



ATTORNEY'S DOCKET PATENT APPLICATION 

062891 . 0297 



14 



telephony devices, with non-IP telephony devices, and even 
with virtual telephony devices. A virtua]^,telephony__dgvice 
may be im plemented as sof tware, fir mware an d/or hardware in 
order to interact with other devices in communication 
5 network 10. Virtual telephony devices may be implemented as 
software or firmware on any existing or dedicated device on 
the IP network. For example, call manager 26a may contain 
software for implementing one or more virtual telephony 
devices 28. Virtual telephony device software or firmware 
10 may also be located on any other network device. The 
computer or other device on^jtfhi ch virtual telephon y 

software is loc_ated._JjicludeL?__Ji^^^!^^ ^ 
c3iE5lIt e?^^readable m edium to store the software, and a 

processor to execute the ^software. 
15 Virtual telephony devices may be logically inserted 

between two or more IP telephony devices to act as an 
intermediary between the two telephony devices. Once such 
a relationship is set up, signaling and media streaming 
that passes through the virtual -te'leph--ony--.4ev^e--may~th§n^ 
be mqdified__t.hrough '^^^ss~translat^^ 
mani-pulWion'f5F"^^^^us _rea^5ns~be ^ore they are sent on to 
£hi~'-distinatIo^device. Reasons for such modifications 
include providing network security, d upl ic ating_streams / 
dynamically redirecting streams, maintaining connections 
25 between devices, converting between data formats (e.g., A- 
Law to |j,-Law) , and injecting media. 

As will be described below, one implementation of 
virtual telephony^device 2 8 is as. a mul.ticast_j.nterTOedi^^ 
that serves^ as an intermediary between one or more uni^ast 

telephony devices and o ne or more multicast telephony^, 

devices to enable multicast telephony devices to 
communicate with each other using multicast streaming. 
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while still allowing unicast telephony devices to 
participate in the telecommunication session. 

In order for a telecommunication session to be 
established through a virtual telephony device (e.g., a 
call placed to IP telephony device 22 in LAN 20 through 
virtual telephony device 28) telephony device 22 first 
registers with virtual telephony device 28. Call_manager 
2 6a instr ucts te lBS^io^^^^e_22_to_^g±§^r^Mi ^ virtua_l .. , 
g;iS^Siy^evlc^28^,at^^ IP-.adg£e£g_3gl.-:£S££=^ 
T'^lephonS^^vTce'2r_signals vir^^^^^ device 28 via 

TCP/IP indl^atir^ that __i t _ jwould_l ike_^,_^ • I f 

virtual telephony device 28 accepts the registration 
request, ^telephony device 22 sends a registration message 
to virtual telephony device 28 using UDP/IP (or any other 
appropriate transmission protocol) . The registration 
message typically comprises information about the telephony 
device such as the telephony device's IP a ndjnedj^access 
ron t-.rol (MAC) addres s.es , the type and capabilities of the 
telephony device, and th^^SHdeclilT^d by the" telephony 
"devTceT 

FIGURE 2 illustrates an exemplary communication link 
created using virtual telephony device 28. It s^ioond be 
noted that although the JtCP and UDP protocols^ are ^ 
specifically identified in ^fH^ following discussion, any 
other suitable signaling and media transmission protocols 
may be used. Virtuaj^eLephony_device_^^ thi s 
communication JJjik_ by_f irst--cr-eat ing_a_logical connect ion 
t^'l^liphony device 22. Creating this logical connection 
-±^^:;j^^;;^^~'^i^^^n^^ UDP and/or TCP ports of 

virtual telephony _device__28 with telephony device 22. 
Vi^riill^, ^'""'^r^^^Y 28 desi gnates o ne of its T C P ports, 

(for example, port 2000) as the sign aling port o_f__tgIgphon>:_ 
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example, port 2100) as the strganiincu,po£fe. for telephony 
device-_2,2_^irtual telephony device 28 may instruct caJJ^ 
^iSi^ger jeT^o^jend^^al^^ 

l^T^rrr^Tl^ii^^ort-aoOO of virtual telephony device 
^flT'Ti^^ser^^iSErTelephony device 2 8 may instruct call 
manager 2 6a to send all media strea ming directed to 
telephony device 22 from other telephony devices to logical 
port 2100 of virtual telephony device 28 Virtual telephony 
ai^;T^i-28~;;d^ automat i^ilif forward "any data that is 
subsequently sent to these ports to telephony device 22 . 

In order to create a communication link between 
teleph5ii7~devI^ii^^^^^J^logical connection _is_also^ 
^;;;i5rT^T^l5h^^r^^ example, telephony device 

^T-;;;;^:^^— ^i^iTTl^iiS^ port of 3000 and a logical 
UDP port of 3100 of virtual telephony device 28. Likewise, 
virtual telephony device 28 may also designate a TCP port 
(for example, port 1000) as the signaling port of call 
manager 26a (data is typically not streamed using RTP to 
and from call manager 26, so a UDP port is usually not 
required) . Virtual telephony device 28 m ay then instruc t 
_telephony devices 22__and__23 (as well as any other 
registered telephony devices) to_ send _ajLl__sjjnaJj^ 
directed to call manager^ j6 a _to_logi.cal_port JL^^ of 
;~;;^rtu-a-l-tele,^S^;dev^^ this manner. UDP_streaming 

between telephony . .devices 22 and_2.3.,. ^ as well _ _a?- T£P 
^gnlling between the_^telephony dey 3^ces_and _piI^maH^^^^^ 
" 2 67Tairb^' transmitVed/v^aTvirtu^ d^ce 28,;; 

FIGURE''r'iirustrates an alternative communication link 

between telephony devices 22 and 23. Although FIGURE 2 
shows the TCP signaling between IP telephony devices and 
call manager 26a being directed through virtual telephony 
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device 28, this signaling may also be directly transmitted 
between call manager 26a and telephony devices 22 and 23. 
in this case, virtual telephony device 28 is used only as 
an intermediary through which RTP streams between telephony 
5 devices 22 and 23 are sent using logical UDP ports 2100 and 
3100 . 

The communication links illustrated in FIGURES 2 and 
3 are used to enable a call between telephony devices 22 
and 23 as follows. Telephony device 23 initially sends a 
10 call initiation request via TCP to call manager 26a 
indicating a desire to communicate with telephony device 
22. Call manager 26a then sends signaling information via 
TCP to telephony device 22 indicating the incoming call 
from telephony device 23. This TCP signaling between 

15 telephony device 23 and call manager 26a may be passed 
through virtual telephony device 28, as illustrated in 
FIGURE 2, or it may be directly transmitted between 
telephony device 23 and call manager 26a, as shown in 
FIGURE 3^f telephony device 22 accepts the call, call 

20 manager 26a establishes_media^^ 

devices 22andJ3__bY_s^^ 
-^^^^^^^^^^OLartual_t,el.e.php,n^^^ 

(aFTP address 200.50.10.30, for example).^ 

When media packets are received at por^t^O^o! virtual 
25 telephony device 28 examines the packets and notes the 
source address of the data. This source address is the IP 
address of telephony device 23, for example, 200.50.10.2, 
and a particular lo gical port of t h e_IP_ad,caress . Since 
t"ili^hSi^rdi^^^i^r2rhas registered with virtual telephony 
30 device 28, virtual telephony device 28 then modifies_Jlie 
source address and port in the header. of_the. IP._packe^s 
^rnTliom" telephony device . 23 to_the IP _f^ffi 
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logical UDP port of virtual telephony device 28 tha^ave_ 
b een a s sociated_^with^el aphony devi^e__23^ (200 . 50 . 10 . 30> 
p^^^^IToon^Vi^t^l " telephonTd^vi^^^^ther^^ 
packets to tere^hSi^T^ice 22. Since the header of each 
5 -paGket--irndi:c5l^s~^Kae-t-Ke-dat-a-stream originated frompor^ 
3100 of virtual telephony device 28, _aPPf5£?_i:^ 
^ili^ony device 22 that t eleEhony_dev.i.ce-2.3 is ac tual ly _ 

_^ -1-r^r-a^-f^f^--aT^^^"th^s3ajd^^Q^ P°^^ • 

'"^ Tsimilar process is performed when telephony device 

10 22 returns a media stream in response to the media stream 
from telephony device 23. Since telephony device 22 
believes that telephony device 23 is located at port 3100 
of virtual telephony device 28, telephony device 22 directs 
its data streaming to this location. When virtual telephony 
15 device 28 receives the IP packets at port 3100, virtual 
telephony device 28 modifies the source IP address and port 
in the packets' header from the source port and IP address 
(200.50.10.1) of telephony device 22 to__port_2100__^ 
virt ual teleph ony_^gvice-28. Virtual telephony device 28 
20 ^hiT^wards'^he packets to telephony device 23 since the 
packets were received at port 3100. Since the header of 
each packet indicates that the data stream originated from 
port 2100 of virtual telephony device 28, it appears to 
telephony device 23 that telephony device 22 is actually 
25 located at this address and port. All subsequent RTP 
streams sent between telephony devices 22 and 2 3 are 
similarly passed through and modified by virtual telephony 
device 28. 

Since all data that is sent between two or more IP 
3 0 telephony devices may be passed through virtual telephony 
device 28, (Virtual telephony device 28 can be used for 
other functions in addition to the address translation 
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function described above. Such uses include serving as an 
intermediary to enable fully functional communication 
between telephony devices that use different types of call 
or control signaling, data compression formats, sizes of 
5 data payloads, audio/video sampling lengths, or any other 
communication parameters that are different between the 
telephony devices. One such use o^j^rtua^J^leph^ 
28 is a s a mul ti ca^T^^rmed iary between_one_o^ore_ 

10 telepho ny devices. 

There are three basic ways to transmit identical data 
to multiple receivers on a packet-based network: broadcast, 
unicast, and multicast. A broadcast is a single data stream 
sent from a single device to every device on a network (or 
15 subnet) . When forwarding a broadcast, routers and switches 
have no way to determine whether devices on a particular 
network actually need or want the data, and a good deal of 
bandwidth may be used unnecessarily. 

To avoid sending unwanted messages to devices, a 
20 source device alternatively can transmit a unicast to each 
intended destination device. Each unicast is an individual 
data stream sent to the particular destination device, 
unlike broadcast, the data stream is not forwarded to 
unintended recipients. However, a separate, but identical, 
25 data stream must be generated for each destination device. 
This is inefficient and consumes network bandwidth. In 
addition, extra processing power and memory is required at 
the source device to generate a message for each 
destination device. 
30 The third option is to send a multicast . A multicast 

is a single data stream that is intended only fo r 
partic;ill^"d^ces that have joined an ap propriat e 
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"multicast groua^" Like a broadcast, the source device 
gZ^^tes a single data stream. Unlike a broadcast, 
however, a multicast-enabled router forwards a multicast 
message to_a particular n^ twork_segment_p^^ when there_are^ 

niultd^astjcecei^ ^^^^ 
di^ce in a network segment leaves a multicast group, the 
router " prunes" the multicast data stream associated with 
that group and stops f <^wardHig.^he_tm^^^^ ..to 
that segment. Therefore, network segments with no multicast 
group members do not have to transmit the multicast 
traffic. Using multicast, bandwidth is saved because only 
a single message is sent from the source device, and this 
message is only transmitted to devices that are members of 
the particular multicast group. 

In order to send IP multicast packets, the s ource 
device specifies a dest inat ion_ address^^hat^ 
m^I^i^st^^^^his destination address may be referred 
to as a (multicast group addressTv, and is typically a Class 
D IP address. To receive multicast packets, an application 
o^rT'di^^ wanting to participate in a multicast group 
^ijaests membership in the multicast groupJ^TMs_me^ 
request is sent to the router on the requesting device'^ 
l5^':"^ndT~if' necessary, the "request is sent to intermediate 
routers in a WAN coupling the requesting device and the 
other devices in the multicast group. 

When a multicast message is sent from a source device 
on another LAN, WAN routers deliver the requested incoming 
multicast packets to each participating device's LAN 
router. The LAN router, whi^ Jia3_mapped__the_jnu 
g roup address t o i^s_assocj^te£hardware (e.g., data link 
layer) address, buildTthe LAN message (e.g., an Ethernet 
frame) using the multicast group address. The participating 
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devices in the LAN (those devices belonging to the 
multicast group) monitor this address and pass the incoming 
multicast messages to the devices' TCP/IP protocol stack, 
which then passes the multicast messages to the appropriate 
application. Thus, mul t icast_lntegrates ^J^^ 
capable of monitoring a m ul t icas t_^roup^^ address_ ( an address 
^EheFThiH'll^rdi^)^^ IP address) and routers 

or similar devices capable of forwarding multicast messages 
to selective networks or network segments based on the 
presence or absence of a multicast group member in a 
particular network or network segment. 

To support IP multicast in a particular embodiment, 
the source and destination devices and the network 
structure between the devices, including intermediate 
routers, are multicast-enabled. The source and destination 
devices have support for IP multicast transmission and 
reception in each device's TCP/IP protocol stack, and have 
software to communicate requests to join a multicast 
group (s) and receive multicast traffic. The devices also 
include network interface cards which filter for LAN data 
link layer addresses mapped from network layer' IP multicast 
addresses, and IP multicast application software such as 
telephony software. 

When using multicast within a LAN segment, no routers 
need be involved for a device to create or join a multicast 
group and share multicast data with other devices on that 
LAN segment. However, when expanding multicast traffic to 
a WAN in one embodiment, the intermediate routers between 
the source and destination devices are mult icast- capable . 
(firewalls can also be reconfigured to permit multicast 
traffic y/ 

Multicasting can be used with IP telephony devices t o 
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enable a telecommunication session between telephony 
devices (e.g., a conference call) . Using a conference call 
^^as an example,' insteadX of~ each telephony device 
transmitting unicast streaming to each of the other 
5 telephony devices participatiW in the conference call, 
each telephony dev ice can tnult^st its media streaming to 
thT multica^r^J^^laddgsrElSh of the participating 
"^t^^Jh^^d^^^l^eT'cin^^ 
participating teliih^y.,devic^^a^lfehe„^^ 
10 '~'Ei^""terephony device then \^i^^^ ^""""^ media A 

streaming received from each, of the other telephony devices 
to form a conference -like inpi^t^^this may be referred to as 
a client summing multicast conference call) . Other uses of 
multicast include transmitting J^music. on hold", or other 
15 media to telephony devices that have been placed on hold, 
and transmitting media streaming to a telephony device so 
that t"he telephony ""de^e~ can monito r a telecommunication 
session between other telephony devices. 

As described above, using multicast streaming dji_the.se_ 
20 applications reduces the total network bandwidth required 
f^ the particular application. However, not all teleph ony 
devices that might participate in the _ conference 
".;;v.^^ '^^T^^ion ^sup port multicast communication^ Examples 
oT~s"^h""iI^cast" telephony devices may include gateways, 
25 computers running unicast telephony software (e.g., 
MICROSOFT NETMEETING) , and unicast IP telephones. 

Standing alone, unicast telephony devices are not able 
to participate in a multicast telecommunication session 
because u nicast^ telephony^ device s are not^,ca Ea^_a.f_ 
3 0 monitoring a muj^i^ast, grou^^ to determine_i|,,a^^ 
—ggg^'bSl^^^^'^t to th7"^i^Il ticast grgug.. Multicast 
^telJSony_,deyii::es-,---.on^the:=^^ can , monitor.^ 
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multicast group address to receive multicast messages, as 



^TT ■^Tlm'^TtSSTng their own_network address to__receive_ 
T^^Ti r^ast^^jg^ broadcast messages . Since unicast telephony 
"d^^^s-a-o- not monitor multicast group addresses, if 
unicast telephony devices are to be directly included in a 
telecommunication session, then _ _all__ of_the-_^^ 
devices must communicate^ using^nicast (and incur the 
di^d^Intages of using this method of communication) . 

However, ^ f_2rmilticast inte rmediary i s_inserted into 
a telecommunication session__on^ ^hal f_ ^ of_^t he , , . ^ gj^^. 
- ^i^S^^^vice (s) 7^e"'u^ii^t telephony device (s) can 
^|btI^e^Srticipate__ j^i_a^ jnujii c a s t J; e lecommuni cation 
slision. using a multicast intermediary, the multicast 
t^^lipKSny devices and the multicast intermediary are able 
to communicate using multicast, and the__mu^ 
interm ediary op erates__to__fo^w;.r-rl the multicast media 
rt:^aming to and receive tnedia^^st^eaimng^fron^^ 
'telephony device u s j^^^gTanl^a^ manner, multicast 

"Tiliphony devices " are able t"o take advantage of the 
multicast feature, while still being able to communicate 
with the unicast telephony devices. 

FIGURE 4 illustrates a communication link established 
between multicast telephony devices 22, 23, 25 and a 
unicast telephony device 64a using a multicast intermediary 
28. The communication link includes a signaling link 
between telephony devices 22, 23, 25, 64a and call manager 
26a, and a media streaming link between the telephony 
devices via a multicast group address 100 and/or multicast 
intermediary 28. Multicast group address 100 represents a 
5SP\nd/or telephony device functionality to establish 
s-3cecute multicast communications, as described above. 
The communication link is initiated when the telephony 
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device initiating the telecominunicatlon__session sends a 
call initi^^H^r, nr^qv^t-. to Call manaqe^J 6^7For example, 
TilipHonS^^^Tlce'l^r'Tagateway) may send a call initiation 
request using TCP signaling 102 (or any other appropriate 
type of signaling) to call manager 26a indicating that PSTN 
telephony device 68a requests a telecommunication session 
(e.g., a conference call) with telephony devices 22, 23 and 
25. In response to this call initiation request, call 
manager 26a signals telephony devices 22, 23 and 25 using 
TCP signaling 102 to indicate the requested 
telecommunication session. If telephony devices 22, 23 and 
25 can participate in the telecommunication session, call 
manager 26a initiates the telecommunication session between 
the telephony devices as follows. 

From registration information previously sent by 
telephony devices 22, 23 and 25 to call manager 26a, c,al3^ 
manage.r_2.6a de.tgrmina s that tele .piiony__devicy^- 7^g=aHd^ ^ 
oTv^ovi- mi-i-l^t icast commu nication. There f or eV^^calljnanager) 
2 6T~^StIblishks a multicast group having a_ multicast group 
'' address^^O^CaTr^JHS^^^^i^'^erT^^^t^^^ telephony devices 
— 22T^2T"and^5^o initiate outgoing media streaming 104 to 
multicast address 100, and to monitor multicas t address 100 
IS^^JI^coming media streaming 106^ rH"thIs manner, T 
multicast telecomm^anicati^JT'^i^ii^ is established between 
telephony devices 22, 23 and 25. 

In addition, call manager 26a determines from either 
registration information or_t^^ea£l=iini^iation request 
^h^t telephony device_64a" is (^imicast^lephony devi^^ 
Therefore, call manager 2 6a determ-ines that a multicast 
i^termediar-y--L-s--nee4ed and generates multicast intermediary 
28r([^^l ^Ji^i^^ger~a^so assocj ;ates^ .. a^ logical jsofT^^o^. 

^-vri-s^^s^STTT^^ 9.8 with each of telephony device 64a j 



mult^i^t-i-mrerrnidi^ 28 with^each of t]e lephony_ device^ 
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5m ^^-^'^^ 



A 



J 



rx 



anG^multicast addre&s 100. As with telephony devices 22, 23 
~'^d^2-5-; — callT^manag^ 26a instructs multicast intermediary 
28 to monitor multicast address 100 for incoming media 
streaming 106 . ( In addition, call_ manager <^26a signals 
5 telephony devic J^;;;;6^a^_to J._n^ti^e^ oulbgo^^^ 



llOfto^the logical port of i^^l^icast inte^rmediar^ 



call'^nager 26a associated with m ult icast addre ss 



10^ 



rAsj^dgs5g3Fb~ed'""ab^v.^"^ 
-aTi^at^ress tr^slation^n media streaming it receives from' 
^either multicast- address 10^ or)telephony device 64a usingi 
--an^Sdresstranslation module^^-^When m ul t i cj ^t^i n t e rmedXary 
2 8 receives incoming media streaming 110 from telephony 
device 64a, it notes the source address in the incoming 
packets, modifies the source addres^^^To^^^ 



13 



^2 0 



i4> 



^^^^ muroTcast intermediary will typically ^^ort or mix media 



multicast "^'^^fmedia^ ' 2 8"^hat is^ associate d with telephony 
d evTce"^ 6TaT~^^ me dia streaminc f^ 104 

^e^^^Tic'ast ad dress 10 0 using a ^com munication modu le . 

forwards media 



Likewise, multicast intermediary 2 8 
streaming 108 that it receives from multicast address 100 
to telephony device 64a as media streaming 108 using the 
communication module (af^tgn^^ f ying ^ ^^g^^^sou^e^a ^ of 
the incoming packets to ^the logical^^ ort of multicai st^ 
int^t^TTedla^>^2^^ a~s^'oc im^d"^\J^Teir'multT^^ s s 

T^^BT^T^^^^^Ho^^ be£5i-e "media streaming 10 8 is forwarded^ 




L/^ W ^ ' 

K^^A^ streaming 104 received from telephony devices 22, 23 "and 



25. Since telephony device 64a is not multicast-capable, it 



V 



' is not to^determine,J^he__ori Qinal source o^ _the^_pa^ke t s 

included in med ia streaming 108 (telephony device 64a 
; 30 .^believes all packets originated at multicast intermediary. 
^fC il 28), and thus telephony device 64a cannot properly sort^nd 
Av^" sequence the incoming dataS Therefore, multicast 
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intermediary can either mix media streaming 104 received 
from telephony devices 22, 23, and 25, sort media streami^ 



104 and indicate to telephony ^device_ 64a that the 

individual streams have dijferenit origins (e.g., by 
i^^dicating different logical ports of multicast 
intermediary 2 8 in the source address of the packets) , or 
it can choose a single media stream 104 from one of 
telephony device 22, 23, and 25 and forward it to telephony 
device 64a . Multicast_JjLtermedJ.a^ _^l,so perform_any 

other type of processing to convert media streaming 106 
received from mul ticast group addres s 100 into a for mat^ 
approfrrSt e"* fo]F^""uni"cas t: ^ eleph o'ny 

y^'^Thr^^ — The ~use^ of multicast intermediary 28, 
telephony device 64a may participate in a multicast 
telecommunication session in which it would not otherwise 
be capable of participating. Although telephony device 64a 
is not directly capable of sending and receiving multicast 
messages, and thus network bandwidth is not saved with 
respect to telephony device 64a, the other telephony 
devices 22, 23, 25 participating in the telecommunication 
session are able to use multicasting to conserve network 
bandwidth. If multicast intermediary 28 was not present in 
the telecommunication session, then telephony devices 22, 
23, 25 would have to communicate using unicast in order to 
allow telephony device 64a to participate, and the 
bandwidth savings of multicast could not be realized. 

FIGURE 5 illustrates a communication link established 
between . telephony devices 22, 23, 25 and two unicast 
telephony devices 64a and 24 (a computer running unicast 
telephony software, such as MICROSOFT NETMEETING) . When 

there are two _ or .more unicast teleph^^ device s, a 

multicast intermediary may be generated for each _unicast 




ATTORNEY'S DOCKET PATENT APPLICATION 

062891 . 0297 

27 

telephony device in order to forward multicast streaming 
from multicast group address 100 to the unicast telephony 
device with which it is associated, as described above. In 
FIGURE 5, for example, multicast intermediary 2 8a forwards 
multicast streaming 106 to telephony device 64a (after any 
appropriate mixing or sorting) , and multicast intermediary 
2 8b forwards multicast streaming 106 to telephony device 24 
(after any appropriate mixing ' or sorting) . Likewise, 
multicast intermediary 28a forwards unicast streaming 110 
sent from telephony device 64a to multicast group address 
100, and multicast intermediary 28b forwards unicast 
streaming 114 from telephony device 24 to multicast group 
address 100. 

FIGURE 6 illustrates an alternate configuration of the 
communication link of FIGURE 5. In this configuration, a 
single multicast intermediary 2 8 forwards multicast 
streaming 106 from multicast group address 100 to unicast 
telephony devices 24 and 64a. Telephony devices 24 and 64a 

are each associated with a di f f eren.t ^Qgi^_^^__PQ^5 

multicast intermediary_28 and multicast intermediary 28 
transmits streaming 106 received from multicast address 100 
to each of these logical ports as described above. 
Likewise, multicast intermediary 2 8 forwards unicast 
streaming 110, 114 from telephony devices 64a and 24, 
respectively, to multicast group address 100. 

Although the present invention has been described with 
several embodiments, a myriad of changes, variations, 
alterations, transformations, and modifications may be 
suggested to one skilled in the art, and it is intended 
that the present invention encompass such changes, 
variations, alterations, transformations, and modifications 
as fall within the spirit and scope of the appended claims. 



